Cookie の設定を選択する

当社は、当社のサイトおよびサービスを提供するために必要な必須 Cookie および類似のツールを使用しています。当社は、パフォーマンス Cookie を使用して匿名の統計情報を収集することで、お客様が当社のサイトをどのように利用しているかを把握し、改善に役立てています。必須 Cookie は無効化できませんが、[カスタマイズ] または [拒否] をクリックしてパフォーマンス Cookie を拒否することはできます。

お客様が同意した場合、AWS および承認された第三者は、Cookie を使用して便利なサイト機能を提供したり、お客様の選択を記憶したり、関連する広告を含む関連コンテンツを表示したりします。すべての必須ではない Cookie を受け入れるか拒否するには、[受け入れる] または [拒否] をクリックしてください。より詳細な選択を行うには、[カスタマイズ] をクリックしてください。

Studio で Amazon EMR クラスターへのアクセスのための IAM ランタイムロールを設定する

フォーカスモード
Studio で Amazon EMR クラスターへのアクセスのための IAM ランタイムロールを設定する - Amazon SageMaker AI

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Studio ノートブックまたは Studio Classic ノートブックから Amazon EMR クラスターに接続すると、ランタイムロールと呼ばれる IAM ロールのリストを視覚的に参照し、臨機応変にそのいずれかを選択できます。その後、ノートブックから作成された Apache Spark、Apache Hive、または Presto のすべてのジョブは、ランタイムロールにアタッチされたポリシーが許可するデータとリソースにのみアクセスするようになります。また、 で管理されているデータレイクからデータにアクセスする場合 AWS Lake Formation、ランタイムロールにアタッチされたポリシーを使用して、テーブルレベルおよび列レベルのアクセスを適用できます。

この機能により、各自がデータへのアクセスレベルに合ったアクセス許可でスコープされたランタイムロールを使用して、自分とチームメイトが同じクラスターに接続できます。また、セッションは共有クラスター上で相互に分離されます。

Studio Classic を使用してこの機能を試すには、「 AWS Lake Formation と Amazon SageMaker Studio Classic の Amazon EMR を使用してきめ細かなデータアクセスコントロールを適用する」を参照してください。このブログ投稿は、事前設定されたランタイムロールを使用して Amazon EMR クラスターへの接続を試すデモ環境をセットアップするのに役立ちます。

前提条件

使用を開始する前に、次の前提条件を満たしていることを確認します。

クロスアカウント接続シナリオ

ランタイムロール認証は、データが Studio アカウントの外にある場合に、さまざまなクロスアカウント接続シナリオをサポートします。次の図は、Studio とデータアカウント間で Amazon EMR クラスター、データ、さらには Amazon EMR 実行ロールを割り当てる 3 つの異なる方法を説明しています。

ランタイム IAM ロール認証でサポートされるクロスアカウントシナリオ。

オプション 1 では、Amazon EMR クラスターと Amazon EMR ランタイム実行ロールは、Studio アカウントとは別のデータアカウントに配置されています。Studio または Studio Classic の実行ロールに Amazon EMR アクセスロールを引き受けるアクセス許可を付与する、別の (Assumable role とも呼ばれる) Amazon EMR アクセスロールのアクセス許可ポリシーを定義します。Amazon EMR アクセスロールは、Studio または Studio Classic の実行ロールに代わって Amazon EMR API GetClusterSessionCredentials を呼び出し、クラスターへのアクセスを許可します。

オプション 2 では、Amazon EMR クラスターと Amazon EMR ランタイム実行ロールは、Studio アカウント内に配置されています。Studio 実行ロールには、Amazon EMR API GetClusterSessionCredentials を使用してクラスターにアクセスするアクセス許可があります。Amazon S3 バケットにアクセスするには、Amazon EMR ランタイム実行ロールにクロスアカウントの Amazon S3 バケットアクセス許可を付与します。このようなアクセス許可は、Amazon S3 バケットポリシー内で付与します。

オプション 3 では、Amazon EMR クラスターは Studio アカウント内にあり、Amazon EMRランタイム実行ロールはデータアカウント内にあります。Studio または Studio Classic の実行ロールには、Amazon EMR API GetClusterSessionCredentials を使用してクラスターにアクセスするアクセス許可が付与されています。Amazon EMR ランタイム実行ロールを実行ロールの設定 JSON に追加します。その後、クラスターを選択するときに UI でロールを選択できます。実行ロール設定 JSON ファイルの設定方法の詳細については、「実行ロールを Studio または Studio Classic にプリロードする」を参照してください。

ランタイム IAM ロールを使用するための Studio の設定

Amazon EMR クラスターのランタイムロール認証を確立するには、必要な IAM ポリシー、ネットワーク、およびユーザビリティの強化を設定します。Amazon EMR クラスター、Amazon EMR ランタイム実行ロール、またはその両方が Studio アカウント以外にある場合、クロスアカウント配置を処理するかどうかによって設定は異なります。次のセクションでは、インストールするポリシー、アカウント間のトラフィックを許可するようにネットワークを設定する方法、Amazon EMR 接続を自動化するために指定するローカル設定ファイルについて説明します。

Amazon EMR クラスターと Studio が同じアカウントにある場合のランタイムロール認証の設定

Amazon EMR クラスターが Studio アカウント内に配置されている場合は、以下の手順を実行して Studio 実行ポリシーに必要なアクセス許可を追加します。

  1. Amazon EMR クラスターに接続するために必要な IAM ポリシーを追加します。詳細については、「Amazon EMR クラスターのリストを設定する」を参照してください。

  2. ポリシーで指定されている、単一または複数の許可済みの Amazon EMR ランタイム実行ロールを渡す際に、Amazon EMR API GetClusterSessionCredentials を呼び出すアクセス許可を付与します。

  3. (オプション) ユーザー定義の命名規則に従った IAM ロールを渡すアクセス許可を付与します。

  4. (オプション) 特定のユーザー定義文字列でタグ付けされた Amazon EMR クラスターにアクセスするアクセス許可を付与します。

  5. Amazon EMR クラスターに接続する際に使用するロールを選択できるように、IAM ロールをプリロードします。IAM ロールをプリロードする方法の詳細については、「実行ロールを Studio または Studio Classic にプリロードする」を参照してください。

次のサンプルポリシーでは、モデリンググループとトレーニンググループに属する Amazon EMR ランタイム実行ロールが GetClusterSessionCredentials を呼び出すことを許可します。さらに、ポリシー所有者は、modeling または training という文字列でタグ付けされた Amazon EMR クラスターにアクセスできます。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "elasticmapreduce:GetClusterSessionCredentials", "Resource": "*", "Condition": { "StringLike": { "elasticmapreduce:ExecutionRoleArn": [ "arn:aws:iam::123456780910:role/emr-execution-role-ml-modeling*", "arn:aws:iam::123456780910:role/emr-execution-role-ml-training*" ], "elasticmapreduce:ResourceTag/group": [ "*modeling*", "*training*" ] } } } ] }

クラスターと Studio が別のアカウントにある場合のランタイムロール認証の設定

Amazon EMR クラスターが Studio アカウントにない場合は、クラスターに接続できるように、SageMaker AI 実行ロールがクロスアカウントの Amazon EMR アクセスロールを引き受けることを許可します。次の手順を実行して、クロスアカウント設定をセットアップします。

  1. SageMaker AI 実行ロールのアクセス許可ポリシーを作成して、実行ロールが Amazon EMR アクセスロールを引き受けられるようにします。次に、ポリシーの例を示します。

    { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAssumeCrossAccountEMRAccessRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::emr_account_id:role/emr-access-role-name" } ] }
  2. 信頼ポリシーを作成して、Amazon EMR アクセスロールを引き受ける信頼された Studio アカウント ID を指定します。次に、ポリシーの例を示します。

    { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCrossAccountSageMakerExecutionRoleToAssumeThisRole", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::studio_account_id:role/studio_execution_role" }, "Action": "sts:AssumeRole" } }
  3. Amazon EMR ランタイム実行ロールに、クラスター上で想定されるタスクを実行するために必要なアクセス許可を付与するように、Amazon EMR アクセスロールのアクセス許可ポリシーを作成します。アクセスロールのアクセス許可ポリシーで指定された Amazon EMR ランタイム実行ロールを使用して GetClusterSessionCredentials API を呼び出すように、Amazon EMR アクセスロールを設定します。次に、ポリシーの例を示します。

    { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCallingEmrGetClusterSessionCredentialsAPI", "Effect": "Allow", "Action": "elasticmapreduce:GetClusterSessionCredentials", "Resource": "", "Condition": { "StringLike": { "elasticmapreduce:ExecutionRoleArn": [ "arn:aws:iam::emr_account_id:role/emr-execution-role-name" ] } } } ] }
  4. アカウント間でトラフィックが行き来できるように、クロスアカウントネットワークを設定します。ガイド付き手順については、「Set up the Amazon EMR クラスターのネットワークアクセスを設定する」を参照してください。このセクションの手順は、以下のタスクを完了するのに役立ちます。

    1. Studio アカウントと Amazon EMR アカウントを VPC ピアリング接続して接続を確立します。

    2. 両方のアカウントのプライベートサブネットルートテーブルにルートを手動で追加します。これにより、Studio アカウントからリモートアカウントのプライベートサブネットへの Amazon EMR クラスターの作成と接続ができるようになります。

    3. Studio ドメインにアタッチされたセキュリティグループを設定してアウトバウンドトラフィックを許可し、Amazon EMR プライマリノードのセキュリティグループを Studio インスタンスのセキュリティグループからのインバウンド TCP トラフィックを許可するように設定します。

  5. Amazon EMR クラスターに接続する際に使用するロールを選択できるように、IAM ランタイムロールをプリロードします。IAM ロールをプリロードする方法の詳細については、「実行ロールを Studio または Studio Classic にプリロードする」を参照してください。

Lake Formation へのアクセスの設定

によって管理されるデータレイクからデータにアクセスする場合 AWS Lake Formation、ランタイムロールにアタッチされたポリシーを使用して、テーブルレベルおよび列レベルのアクセスを適用できます。Lake Formation へのアクセス許可を設定するには、「Integrate Amazon EMR with AWS Lake Formation」を参照してください。

実行ロールを Studio または Studio Classic にプリロードする

Amazon EMR クラスターに接続する際に使用するロールを選択できるように、IAM ランタイムロールをプリロードできます。Studio の JupyterLab のユーザーは、SageMaker AI コンソールまたは提供されたスクリプトを使用できます。

Preload runtime roles in JupyterLab using the SageMaker AI console

SageMaker AI コンソールを使用してランタイムロールをユーザープロファイルまたはドメインに関連付けるには:

  1. https://console.aws.amazon.com/sagemaker/ で SageMaker AI コンソールに移動します。

  2. 左側のナビゲーションペインでドメインを選択し、アクセス許可を更新した SageMaker AI 実行ロールを使用してドメインを選択します。

    • ランタイム (クロスアカウントのユースケースの場合は、ランタイムとアクセスロール) をドメインに追加するには: [ドメインの詳細] ページの[アプリケーション設定] タブで、[JupyterLab] セクションに移動します。

    • ランタイム (およびクロスアカウントユースケースのアクセスロール) をユーザープロファイルに追加するには: ドメインの詳細ページで、ユーザープロファイルタブを選択し、アクセス許可を更新した SageMaker AI 実行ロールを使用してユーザープロファイルを選択します。[アプリケーション設定] タブで、[JupyterLab] セクションに移動します。

  3. [編集] を選択して、アクセスロール (引き受けられるロール) と EMR Serverless ランタイム実行ロールの ARN を追加します。

  4. [送信] を選択します。

次に Amazon EMR サーバーに接続すると、ランタイムロールがドロップダウンメニューに表示されて選択できるようになります。

Preload runtime roles in JupyterLab using a Python script

アクセス許可を更新した SageMaker AI 実行ロールを使用してスペースから開始された JupyterLab アプリケーションで、ターミナルで次のコマンドを実行します。domainIDuser-profile-nameemr-accountIDEMRServiceRole は、実際の適切な値に置き換えます。このコードスニペットは、クロスアカウントのユースケースで SageMaker AI ドメイン内のユーザープロファイル設定 (client.update_user_profile) を更新します。具体的には、Amazon EMR のサービスロールを設定します。JupyterLab アプリケーションが Amazon EMR アカウント内で Amazon EMR を実行するための特定の IAM ロール (AssumableRole または AccessRole) を引き受けることを許可します。

スペースがドメインレベルで設定された実行ロールを使用している場合は、client.update_domain を使用してドメイン設定を更新することもできます。

import botocore.session import json sess = botocore.session.get_session() client = sess.create_client('sagemaker') client.update_user_profile( DomainId="domainID", UserProfileName="user-profile-name", UserSettings={ 'JupyterLabAppSettings': { 'EmrSettings': { 'AssumableRoleArns': ["arn:aws:iam::emr-accountID:role/AssumableRole"], 'ExecutionRoleArns': ["arn:aws:iam::emr-accountID:role/EMRServiceRole", "arn:aws:iam::emr-accountID:role/AnotherServiceRole"] } } }) resp = client.describe_user_profile(DomainId="domainID", UserProfileName=user-profile-name") resp['CreationTime'] = str(resp['CreationTime']) resp['LastModifiedTime'] = str(resp['LastModifiedTime']) print(json.dumps(resp, indent=2))
Preload runtime roles in Studio Classic

AccessRole (AssumableRole) の ARN を SageMaker AI 実行ロールに提供します。Jupyter サーバーは起動時にこの ARN をロードします。Studio が使用する実行ロールは、信頼するアカウントの Amazon EMR クラスターを検出して接続するクロスアカウントロールを想定しています。

この情報は、ライフサイクル設定 (LCC) スクリプトを使用して指定できます。LCC は、ドメインまたは特定のユーザープロファイルにアタッチできます。使用する LCC スクリプトは JupyterServer 設定である必要があります。LCC スクリプトを作成する方法の詳細については、「Use Lifecycle Configurations with Studio Classic」を参照してください。

以下は LCC スクリプトの例です。スクリプトを変更するには、AssumableRoleemr-account をそれぞれの値に置き換えます。クロスアカウントの数は、最大 5 つに制限されています。

以下のスニペットは、Studio Classic アプリケーションとクラスターが同じアカウントにある場合に適用できる LCC bash スクリプトの例です。

#!/bin/bash set -eux FILE_DIRECTORY="/home/sagemaker-user/.sagemaker-analytics-configuration-DO_NOT_DELETE" FILE_NAME="emr-configurations-DO_NOT_DELETE.json" FILE="$FILE_DIRECTORY/$FILE_NAME" mkdir -p $FILE_DIRECTORY cat << 'EOF' > "$FILE" { "emr-execution-role-arns": { "123456789012": [ "arn:aws:iam::123456789012:role/emr-execution-role-1", "arn:aws:iam::123456789012:role/emr-execution-role-2" ] } } EOF

Studio Classic アプリケーションとクラスターが別々のアカウントにある場合は、クラスターを使用できる Amazon EMR アクセスロールを指定します。以下のサンプルポリシーでは、123456789012 が Amazon EMR クラスターのアカウント ID で、212121212121434343434343 は、許可済みの Amazon EMR アクセスロールの ARN です。

#!/bin/bash set -eux FILE_DIRECTORY="/home/sagemaker-user/.sagemaker-analytics-configuration-DO_NOT_DELETE" FILE_NAME="emr-configurations-DO_NOT_DELETE.json" FILE="$FILE_DIRECTORY/$FILE_NAME" mkdir -p $FILE_DIRECTORY cat << 'EOF' > "$FILE" { "emr-execution-role-arns": { "123456789012": [ "arn:aws:iam::212121212121:role/emr-execution-role-1", "arn:aws:iam::434343434343:role/emr-execution-role-2" ] } } EOF # add your cross-account EMR access role FILE_DIRECTORY="/home/sagemaker-user/.cross-account-configuration-DO_NOT_DELETE" FILE_NAME="emr-discovery-iam-role-arns-DO_NOT_DELETE.json" FILE="$FILE_DIRECTORY/$FILE_NAME" mkdir -p $FILE_DIRECTORY cat << 'EOF' > "$FILE" { "123456789012": "arn:aws:iam::123456789012:role/cross-account-emr-access-role" } EOF

SageMaker AI コンソールを使用してランタイムロールをユーザープロファイルまたはドメインに関連付けるには:

  1. https://console.aws.amazon.com/sagemaker/ で SageMaker AI コンソールに移動します。

  2. 左側のナビゲーションペインでドメインを選択し、アクセス許可を更新した SageMaker AI 実行ロールを使用してドメインを選択します。

    • ランタイム (クロスアカウントのユースケースの場合は、ランタイムとアクセスロール) をドメインに追加するには: [ドメインの詳細] ページの[アプリケーション設定] タブで、[JupyterLab] セクションに移動します。

    • ランタイム (およびクロスアカウントユースケースのアクセスロール) をユーザープロファイルに追加するには: ドメインの詳細ページで、ユーザープロファイルタブを選択し、アクセス許可を更新した SageMaker AI 実行ロールを使用してユーザープロファイルを選択します。[アプリケーション設定] タブで、[JupyterLab] セクションに移動します。

  3. [編集] を選択して、アクセスロール (引き受けられるロール) と EMR Serverless ランタイム実行ロールの ARN を追加します。

  4. [送信] を選択します。

次に Amazon EMR サーバーに接続すると、ランタイムロールがドロップダウンメニューに表示されて選択できるようになります。

プライバシーサイト規約Cookie の設定
© 2025, Amazon Web Services, Inc. or its affiliates.All rights reserved.