翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
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)」を参照してください。
注記
現在、クロスリージョン AWS SDK 統合とクロスリージョン AWS リソースアクセスは Step Functions では使用できません。
クロスアカウントの主なリソースの概念
- 実行ロール
-
Step Functions がコードを実行し、 AWS Lambda 関数の呼び出しアクションなどの AWS リソースにアクセスするために使用する IAM ロール。
- サービス統合
-
ワークフロー
Task内の状態から呼び出すことができる AWS SDK 統合 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 Service AssumeRoleサポートする文字のみを含める必要があります。詳細については、「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 ポリシーを生成する方法」を参照してください。サンプルポリシーによる 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:*"
]
}
]
}