翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Step Functions での他の AWS アカウントのリソースへのアクセス
Step Functions は、ワークフローAWS アカウントのさまざまな で設定されたリソースへのクロスアカウントアクセスを提供します。Step Functions サービス統合を使用すると、 がAWSリソースベースのポリシーまたはクロスアカウント呼び出しをサポートAWS のサービスしていない場合でも、任意のクロスアカウントリソースを呼び出すことができます。
たとえば、開発とテストという AWS アカウント2 つの を同じ に所有しているとしますAWS リージョン。クロスアカウントアクセスを使用すると、「Development」アカウントのワークフローは、「Testing」アカウントで使用可能な Amazon S3 バケット、Amazon DynamoDB テーブル、Lambda 関数などのリソースにアクセスできます。
重要
IAM ロールとリソースベースのポリシーは、単一のパーティション内のアカウント間でのみアクセスを委任します。例えば、標準 aws パーティションの米国西部 (北カリフォルニア)と、aws-cn パーティションの中国 (北京) にアカウントがあるとします。中国 (北京) アカウントの Amazon S3 リソースベースのポリシーを使用して、標準 aws アカウントのユーザーにアクセスを許可することはできません。
クロスアカウントアクセスの詳細については、「IAM ユーザーガイド」の「クロスアカウントポリシーの評価論理」を参照してください。
各 は独自のリソースを完全に制御AWS アカウントしますが、Step Functions を使用すると、コードをカスタマイズすることなくワークフロー内のステップを再編成、スワップ、追加、または削除できます。これは、プロセスが変わったりアプリケーションが進化したりしても可能です。
また、ネストしたステートマシンの実行を呼び出して、さまざまなアカウントで利用可能にすることもできます。これにより、ワークフローを効率的に分離して切り離すことができます。異なるアカウントの別の Step Functions ワークフローにアクセスするワークフローの中で、.sync サービス統合パターンを使用する場合、Step Functions のポーリングは自身の割り当てクオータを消費します。詳細については、「ジョブの実行 (.sync)」を参照してください。
注記
クロスリージョン AWSSDK 統合とクロスリージョンAWSリソースアクセスは、Step Functions では使用できません。
クロスアカウントの主なリソースの概念
- 実行ロール
-
Step Functions がコードを実行し、AWS Lambda関数の呼び出しアクションなどのAWSリソースにアクセスするために使用する IAM ロール。
- サービス統合
-
ワークフロー
Taskの状態内から呼び出すことができる AWSSDK 統合 API アクション。 - ソースアカウント
ステートマシンAWS アカウントを所有し、実行を開始した 。
- ターゲットアカウント
クロスアカウント呼び出しを行う AWS アカウント。
- ターゲットロール
ターゲットアカウントが所有するリソースへの呼び出しを行う際に、ステートマシンが引き受けるターゲットアカウントの IAM ロール
- ジョブの実行 (.sync)
などの サービスを呼び出すために使用されるサービス統合パターンAWS Batch。またこれにより、 Step Functions のステートマシンはジョブの完了まで待機してから次の状態に進みます。Step Functions の待機を指示するには、
Task状態のResourceフィールドに.syncサフィックスを追加します。
クロスアカウントリソースの呼び出し
ワークフローで、クロスアカウントリソースを呼び出すには次の操作を行います。
リソースを含むターゲットアカウントに IAM ロールを作成します。このロールは、ステートマシンを含むソースアカウントに、ターゲットアカウントのリソースにアクセスするアクセス許可を付与します。
Taskステートの定義で、クロスアカウントリソースを呼び出す前にステートマシンが引き受けるターゲット IAM ロールを指定します。ターゲット IAM ロールの信頼ポリシーを変更して、ソースアカウントがこのロールを一時的に引き受けることができるようにします。信頼ポリシーには、ソースアカウントで定義したステートマシンの Amazon リソースネーム (ARN) を含める必要があります。また、AWSリソースを呼び出すための適切なアクセス許可をターゲット IAM ロールに定義します。
ソースアカウントの実行ロールを更新して、ターゲット IAM ロールを引き受けるのに必要なアクセス許可を含めます。
例として、チュートリアルの「Step Functions でのクロスアカウントAWSリソースへのアクセス」を参照してください。
注記
複数の AWS アカウント からリソースにアクセスするための IAM ロールを引き受けるようにステートマシンを設定できます。ただし、ステートマシンが一度に引き受けられる IAM ロールは、1 つだけです。
.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 フィールドでは、ロールを引き受けられるユーザーをさらに制御できます。ステートマシンの名前には、API がAWS Security Token ServiceAssumeRoleサポートする文字のみを含める必要があります。詳細については、「AWS Security Token Service API リファレンス」の「AssumeRole」を参照してください。
{ "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 ポリシーを生成する方法」を参照してください。例えばステートマシンを起動するには、以下の許可を追加します。
-
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "states:StartExecution" ], "Resource": [ "arn:aws:states:us-east-1:123456789012:stateMachine:myStateMachineName" ] }, { "Effect": "Allow", "Action": [ "states:DescribeExecution", "states:StopExecution" ], "Resource": [ "arn:aws:states:us-east-1:123456789012:execution:myStateMachineName:*" ] } ] }