Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Activer les requêtes fédérées entre comptes
La requête fédérée vous permet d'interroger des sources de données autres qu'Amazon S3 à l'aide de connecteurs de source de données déployés sur AWS Lambda. La fonction de requête fédérée entre comptes permet à la fonction Lambda et aux sources de données à interroger d'être localisées dans différents comptes.
En tant qu'administrateur de données, vous pouvez activer les requêtes fédérées entre comptes en partageant votre connecteur de données avec le compte d'un analyste de données ou, en tant qu'analyste de données, en utilisant une Lambda partagée par un administrateur ARN de données à ajouter à votre compte. Lorsque des modifications de configuration sont apportées à un connecteur du compte d'origine, la configuration mise à jour est automatiquement appliquée aux instances partagées du connecteur dans les comptes d'autres utilisateurs.
Considérations et restrictions
-
La fonction de requête fédérée entre comptes est disponible pour les connecteurs de données de métastores non Hive qui utilisent une source de données Lambda.
-
La fonctionnalité n'est pas disponible pour le type de source de AWS Glue Data Catalog données. Pour plus d'informations sur l'accès entre comptes à AWS Glue Data Catalog s, consultezConfigurer l'accès entre comptes à AWS Glue catalogues de données.
-
Si la réponse de la fonction Lambda de votre connecteur dépasse la limite de taille de réponse Lambda de 6 Mo, Athena chiffre, regroupe et déverse automatiquement la réponse dans un compartiment Amazon S3 que vous configurez. L'entité qui exécute la requête Athena doit avoir accès à l'emplacement du déversement pour qu'Athéna puisse lire les données déversées. Nous vous recommandons de définir une politique de cycle de vie Amazon S3 afin de supprimer les objets présents sur le lieu du déversement, car les données ne sont plus nécessaires une fois la requête terminée.
-
L'utilisation de requêtes fédérées n' Régions AWS est pas prise en charge.
Autorisations nécessaires
Pour configurer les autorisations requises, des actions doivent être effectuées à la fois dans le compte A et dans le compte B.
Actions pour le compte A
Pour que le compte administrateur de données A partage une fonction Lambda avec le compte d'analyste de données B, le compte B nécessite la fonction d'invocation Lambda et l'accès au compartiment de déversement. Par conséquent, le compte A devrait ajouter une politique basée sur les ressources à la fonction Lambda et l'accès principal à son compartiment de déversement dans Amazon S3.
-
La politique suivante accorde des autorisations de fonction d'invocation Lambda au compte B sur une fonction Lambda dans le compte A.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "CrossAccountInvocationStatement", "Effect": "Allow", "Principal": { "AWS": ["arn:aws:iam::
account-B-id
:user/username
"] }, "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:aws-region
:account-A-id
:function:lambda-function-name
" } ] } -
La politique suivante permet d'accéder au compartiment de déversement au principal dans le compte B.
{ "Version": "2008-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": ["arn:aws:iam::
account-B-id
:user/username
"] }, "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::spill-bucket
", "arn:aws:s3:::spill-bucket
/*" ] } ] } -
Si la fonction Lambda chiffre le bucket spill avec une AWS KMS clé au lieu du chiffrement par défaut proposé par la fédérationSDK, la politique de AWS KMS clés du compte A doit accorder l'accès à l'utilisateur du compte B, comme dans l'exemple suivant.
{ "Sid": "Allow use of the key", "Effect": "Allow", "Principal": { "AWS": ["arn:aws:iam::
account-B-id
:user/username
"] }, "Action": [ "kms:Decrypt" ], "Resource": "*" // Resource policy that gets placed on the KMS key. }
Actions pour le compte B
Pour que le compte A partage son connecteur avec le compte B, le compte B doit créer un rôle appelé AthenaCrossAccountCreate-
que le compte A assume en appelant l'AssumeRoleAPIaction AWS Security Token Service.account-A-id
-
Utilisez la IAM console ou le AWS CLI pour créer le
AthenaCrossAccountCreate-
rôle en tant que rôle de politique de confiance personnalisé. Une politique de confiance personnalisée délègue l'accès et permet à d'autres personnes d'effectuer des actions sur votre AWS compte. Pour connaître les étapes à suivre, voir Création d'un rôle à l'aide de politiques de confiance personnalisées dans le Guide de IAM l'utilisateur.account-A-id
La relation de confiance doit avoir un objet principal dans lequel la clé se trouve
AWS
et la valeur est ARN celle du compte A, comme dans l'exemple suivant.... "Principal": { "AWS": ["arn:aws:iam::
account-A-id
:user/username
"] }, ... -
Également dans le compte B, créez une politique comme la suivante qui autorise l'
CreateDataCatalog
action.{ "Effect": "Allow", "Action": "athena:CreateDataCatalog", "Resource": "arn:aws:athena:*:
account-B-id
:datacatalog/*" } -
Ajoutez la politique qui autorise l'
CreateDataCatalog
action auAthenaCrossAccountCreate-
rôle que vous avez créé à l'aide du compte B.account-A-id
Partage d'une source de données dans le compte A avec le compte B
Une fois les autorisations en place, vous pouvez utiliser la page Data sources (Sources de données) dans la console Athena pour partager un connecteur de données dans votre compte (compte A) avec un autre compte (compte B). Le compte A conserve le contrôle total et la propriété du connecteur. Lorsque le compte A modifie la configuration du connecteur, la configuration mise à jour s'applique au connecteur partagé dans le compte B.
Pour partager une source de données Lambda du compte A avec le compte B
Ouvrez la console à l'adresse https://console.aws.amazon.com/athena/
. Si le panneau de navigation de la console n'est pas visible, choisissez le menu d'extension sur la gauche.
-
Choisissez Sources de données.
-
Sur la page Data sources (Sources de données), choisissez le lien du connecteur que vous souhaitez partager.
-
Sur la page de détails d'une source de données Lambda, dans le menu Actions situé dans le coin supérieur droit, choisissez Partager.
-
Dans le partage
Lambda-name
avec un autre compte ? dans une boîte de dialogue, entrez les informations requises.-
Pour Data source name (Nom de la source de données), saisissez le nom de la source de données copiée telle que vous souhaitez qu'elle apparaisse dans l'autre compte.
-
Pour Account ID (ID de compte), saisissez l'ID du compte avec lequel vous souhaitez partager votre source de données (dans ce cas, compte B).
-
-
Choisissez Partager. Le connecteur de données partagées que vous avez spécifié est créé dans le compte B. Les modifications de configuration apportées au connecteur dans le compte A s'appliquent au connecteur du compte B.
Ajout d'une source de données partagée du compte A au compte B
En tant qu'analyste de données, un administrateur ARN de données peut vous fournir un connecteur à ajouter à votre compte. Vous pouvez utiliser la page Sources de données de la console Athena pour ajouter le Lambda ARN fourni par votre administrateur à votre compte.
Pour ajouter le Lambda ARN d'un connecteur de données partagé à votre compte
Ouvrez la console à l'adresse https://console.aws.amazon.com/athena/
. -
Si le volet de navigation n'est pas visible, choisissez le menu d'extension sur la gauche.
-
Choisissez Sources de données.
-
À la page Data sources (Sources de données), choisissez Connect data source (Connecter la source de données).
-
Sur la page Choisir une source de données, sélectionnez Connecteur personnalisé ou partagé.
-
Choisissez Suivant.
-
Sur la page Entrer les détails de la source de données, dans la section Détails de la connexion, pour Sélectionner ou saisir une fonction Lambda, entrez le ARN Lambda du compte A.
-
Choisissez Suivant.
-
Sur la page Réviser et créer, choisissez Créer une source de données.
Résolution des problèmes
Si vous recevez un message d'erreur indiquant que le compte A ne dispose pas des autorisations nécessaires pour assumer un rôle dans le compte B, assurez-vous que le nom du rôle créé dans le compte B est correctement orthographié et que la politique appropriée est attachée.