他の のリソースへのアクセス AWS アカウント Step Functions の - AWS Step Functions

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

他の のリソースへのアクセス AWS アカウント Step Functions の

Step Functions は、異なる で設定されたリソースへのクロスアカウントアクセスを提供します。 AWS アカウント ワークフロー内の 。Step Functions サービス統合を使用して、任意のクロスアカウントを呼び出すことができます。 AWS リソースは、 AWS のサービス は、リソースベースのポリシーやクロスアカウント呼び出しをサポートしていません。

例えば、2 つの を所有しているとします。 AWS アカウント開発とテストと呼ばれる は、同じ で AWS リージョン。 クロスアカウントアクセスを使用すると、開発アカウントのワークフローは、テストアカウントで使用できる Amazon S3 バケット、Amazon DynamoDB テーブル、Lambda 関数などの リソースにアクセスできます。

重要

IAM ロールとリソースベースのポリシーは、単一のパーティション内でのみアカウント間のアクセスを委任します。例えば、標準 aws パーティションの米国西部 (北カリフォルニア)と、aws-cn パーティションの中国 (北京) にアカウントがあるとします。中国 (北京) アカウントの Amazon S3 リソースベースのポリシーを使用して、標準 aws アカウントのユーザーにアクセスを許可することはできません。

クロスアカウントアクセスの詳細については、「 ユーザーガイド」の「クロスアカウントポリシーの評価ロジックIAM」を参照してください。

ただし、それぞれ AWS アカウント は独自のリソースを完全に制御し、Step Functions を使用すると、コードをカスタマイズしなくてもワークフロー内のステップを再編成、スワップ、追加、または削除できます。これは、プロセスが変わったりアプリケーションが進化したりしても可能です。

また、ネストしたステートマシンの実行を呼び出して、さまざまなアカウントで利用可能にすることもできます。これにより、ワークフローを効率的に分離して切り離すことができます。異なるアカウントの別の Step Functions ワークフローにアクセスするワークフローの中で、.sync サービス統合パターンを使用する場合、Step Functions のポーリングは自身の割り当てクオータを消費します。詳細については、「ジョブの実行 (.sync)」を参照してください。

注記

現在、クロスリージョン AWS SDK 統合とクロスリージョン AWS リソースアクセスは Step Functions では使用できません。

クロスアカウントリソースの主要な概念

実行ロール

Step Functions がコードの実行とアクセスに使用する IAMロール AWS などの リソース AWS Lambda 関数の呼び出しアクション。

サービス統合

- AWS SDK ワークフロー内のTask状態内から呼び出すことができる 統合APIアクション。

ソースアカウント

An AWS アカウント ステートマシンを所有し、実行を開始した 。

ターゲットアカウント

An AWS アカウント クロスアカウント呼び出しを行う 。

ターゲットロール

ターゲットアカウントが所有するリソースを呼び出すためにステートマシンが引き受けるターゲットアカウントのIAMロール。

ジョブの実行 (.sync)

などの サービスを呼び出すために使用されるサービス統合パターン AWS Batch。 また、Step Functions ステートマシンはジョブが完了するのを待ってから次の状態に進みます。Step Functions の待機を指示するには、Task 状態の Resource フィールドに .sync サフィックスを追加します。

クロスアカウントリソースの呼び出し

ワークフローで、クロスアカウントリソースを呼び出すには次の操作を行います。

  1. リソースを含む IAMロールをターゲットアカウントに作成します。このロールは、ステートマシンを含むソースアカウントに、ターゲットアカウントのリソースにアクセスするアクセス許可を付与します。

  2. Task ステートの定義で、クロスアカウントリソースを呼び出す前に、ステートマシンが引き受けるターゲットIAMロールを指定します。

  3. ターゲットIAMロールの信頼ポリシーを変更して、ソースアカウントがこのロールを一時的に引き受けることを許可します。信頼ポリシーには、ソースアカウントで定義されたステートマシンの Amazon リソースネーム (ARN) を含める必要があります。また、 を呼び出すための適切なアクセス許可をターゲットIAMロールに定義します。 AWS リソース。

  4. ソースアカウントの実行ロールを更新して、ターゲットIAMロールを引き受けるために必要なアクセス許可を含めます。

例については、チュートリアルクロスアカウントへのアクセス AWS Step Functions の リソースの「」を参照してください。

注記

複数の からリソースにアクセスするための IAMロールを引き受けるようにステートマシンを設定できます。 AWS アカウント。 ただし、ステートマシンは一度に 1 つのIAMロールのみを引き受けることができます。

クロスアカウントリソースへのアクセス概念図

.sync 統合パターンへのクロスアカウントアクセス

ワークフローで .sync サービス統合パターンを使用すると、Step Functions は呼び出されたクロスアカウントリソースをポーリングして、タスクの完了を確認します。これにより、実際のタスク完了時間と Step Functions がタスク完了を認識する時間との間に若干の遅延が生じます。ターゲットIAMロールには、このポーリングループを完了するために.sync呼び出しに必要なアクセス許可が必要です。これを行うには、ターゲットIAMロールに、ソースアカウントが引き受けることを許可する信頼ポリシーが必要です。さらに、ターゲットIAMロールにはポーリングループを完了するために必要なアクセス許可が必要です。

注記

現在、arn:aws:states:::states:startExecution.sync はネストされた Express ワークフローをサポートしていません。代わりに arn:aws:states:::aws-sdk:sfn:startSyncExecution を使用します。

.sync 呼び出しのための信頼ポリシーの更新

次の例に示すように、ターゲットIAMロールの信頼ポリシーを更新します。sts:ExternalId フィールドでは、ロールを引き受けられるユーザーをさらに制御できます。ステートマシンの名前には、 AWS Security Token Service AssumeRole API は をサポートしています。詳細については、「」のAssumeRole「」を参照してください。 AWS Security Token Service API リファレンス

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Principal": { "AWS": "arn:aws:iam::sourceAccountID:role/InvokeRole", }, "Condition": { "StringEquals": { "sts:ExternalId": "arn:aws:states:us-east-2:sourceAccountID:stateMachine:stateMachineName" } } } ] }

.sync 呼び出しに必要な許可

ステートマシンに必要なアクセス許可を付与するには、ターゲットIAMロールに必要なアクセス許可を更新します。詳細については、「Step Functions が統合サービスのIAMポリシーを生成する方法」を参照してください。サンプルポリシーからの Amazon アクセス EventBridge 許可は必要ありません。例えばステートマシンを起動するには、以下の許可を追加します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "states:StartExecution" ], "Resource": [ "arn:aws:states:region:accountID:stateMachine:stateMachineName" ] }, { "Effect": "Allow", "Action": [ "states:DescribeExecution", "states:StopExecution" ], "Resource": [ "arn:aws:states:region:accountID:execution:stateMachineName:*" ] } ] }