Accessing resources in other AWS accounts in your workflows
Step Functions provides cross-account access to resources configured in different AWS accounts in your workflows. Using Step Functions service integrations, you can invoke any cross-account AWS resource even if that AWS service doesn’t support resource-based policies or cross-account calls.
For example, assume you own two AWS accounts, called Development and Testing, in the same AWS Region. Using cross-account access, your workflow in the Development account can access resources, such as Amazon S3 buckets, Amazon DynamoDB tables, and Lambda functions that are available in the Testing account.
Important
IAM roles and resource-based policies delegate access across accounts only within a single partition. For example, assume that you have an account in
US West (N. California) in the standard aws
partition. You also have an account in China (Beijing) in the aws-cn
partition. You can't use an Amazon S3
resource-based policy in your account in China (Beijing) to allow access for users in your standard aws
account.
For more information about cross-account access, see Cross-account policy evaluation logic in the IAM User Guide.
Although each AWS account maintains complete control over its own resources, with Step Functions, you can reorganize, swap, add, or remove steps in your workflows without the need to customize any code. You can do this even as the processes change or applications evolve.
You can also invoke executions of nested state machines so they're available across different accounts. Doing so efficiently separates and isolates your workflows. When you use the .sync service integration pattern in your workflows that access another Step Functions workflow in a different account, Step Functions uses polling that consumes your assigned quota. For more information, see Run a Job (.sync).
Note
Currently, cross-Region AWS SDK integration and cross-Region AWS resource access aren't available in Step Functions.
Contents
Key concepts in this topic
- Execution role
-
An IAM role that Step Functions uses to run code and access AWS resources, such as the AWS Lambda function's Invoke action.
- Service integration
-
The AWS SDK integration API actions that can be called from within a
Task
state in your workflows. - source account
An AWS account that owns the state machine and has started its execution.
- target account
An AWS account to which you make cross-account calls.
- target role
An IAM role in the target account that the state machine assumes for making calls to resources that the target account owns.
- Run a Job (.sync)
A service integration pattern used to call services, such as AWS Batch. It also makes a Step Functions state machine wait for a job to complete before progressing to the next state. To indicate that Step Functions should wait, append the
.sync
suffix in theResource
field in yourTask
state definition.
Invoking cross-account resources
To invoke a cross-account resource in your workflows, do the following:
Create an IAM role in the target account that contains the resource. This role grants the source account, containing the state machine, permissions to access the target account's resources.
In the
Task
state's definition, specify the target IAM role to be assumed by the state machine before invoking the cross-account resource.Modify the trust policy in the target IAM role to allow the source account to assume this role temporarily. The trust policy must include the Amazon Resource Name (ARN) of the state machine defined in the source account. Also, define the appropriate permissions in the target IAM role to call the AWS resource.
Update the source account’s execution role to include the required permission for assuming the target IAM role.
For an example, see Tutorial: Accessing cross-account AWS resources.
Note
You can configure your state machine to assume an IAM role for accessing resources from multiple AWS accounts. However, a state machine can assume only one IAM role at a given time.