-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stepfunctions-tasks: Step Functions task for cross-region AWS API call #29918
stepfunctions-tasks: Step Functions task for cross-region AWS API call #29918
Comments
Awesome! Love this idea. Thank you @tmokmss !! |
Would love to use this feature soon! We were having to write custom lambdas to take care of the calls but this would be pretty useful if it comes out of the box. |
This can also be useful to call Bedrock client API (InvokeModel), because currently the supported regions are limited (even only us-west-2 for Claude Opus) and often requires cross-region API call. |
…PI call (#30061) ### Issue # (if applicable) Closes #29918. ### Reason for this change It would be useful if we could call AWS API across regions from a Step Functions state machine. Currently it is not officially supported even with AWS SDK integration tasks. Our usecase is to automate a cross-region failover scenario in a multi-region application. This requires you to orchestrate multiple API calls for both active and standby regions (e.g. failover Aurora DB cluster, rewrite AppConfig parameter, etc), and it would be great if we can manage these operations in a single state machine. ### Description of changes This PR adds a new construct `CallAwsServiceCrossRegion` that deploys 1. a Lambda function to call AWS API in different regions 2. SFn task to call the function. Because most properties are compatible with the existing `CallAwsService` construct, you can use the new construct by just adding the `region` property. Additionally, it also allows to set `endpoint` to override AWS API endpoint, because some AWS APIs requires you to override it. (e.g. [Route53 ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/getting-started-cli-routing.control-state.html)) ### Description of how you validated changes Added unit tests and integ tests. ### Checklist - [X] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
Comments on closed issues and PRs are hard for our team to see. If you need help, please open a new issue that references this one. |
Describe the feature
It would be useful if we could call AWS API across regions from a Step Functions state machine.
Currently it is not officially supported even with AWS SDK integration tasks.
Use Case
My usecase is to automate cross-region failover in a multi-region application. This requires you to orchestrate multiple API calls for both active and standby regions (e.g. failover Aurora DB cluster, rewrite AppConfig parameter, etc), and it would be great if we can manage these operations in a single state machine.
Proposed Solution
Add a construct like
CallAwsServiceAcrossRegion
in theaws-stepfunctions-tasks
module. The API would be similar to the existingCallAwsService
task, with an additional propertyregion
.In the new construct, we create a Lambda function to proxy the API request to the target region, use
LambdaInvoke
task internally, and call AWS API from the function.I wrote an example Lambda function to proxy AWS API requests: https://gist.github.com/tmokmss/aeb85fc8c3076cbc5d9ae1c6698969d1
The alternative option would be adding a property like
region
toCallAwsService
task, but it could potentially make a breaking change when SFn would officially start to support cross-region AWS API call. That is why I think the above approach (creating a brand new construct) is better.Other Information
No response
Acknowledgements
CDK version used
2.138.0
Environment details (OS name and version, etc.)
n/a
The text was updated successfully, but these errors were encountered: