Open RichiCoder1 opened 2 years ago
Thanks Richard for opening the enhancement request. From our side this isn't in our roadmap right now. If there's more asks from the customers then we can readjust the priority accordingly.
If you get a chance to contribute the changes we can definitely review and get it merged considering the risk factors.
It's nothing amazing and still pretty raw, but I created a PoC CDK construct: https://github.com/RichiCoder1/elastic-serverless-forwarder-cdk
Building and deploying CDK constructs are kind of a beast unto their own so not sure how best to PR it into this repo.
Thanks Richard for reaching out to us again and for the valuable time you spent for this PoC. I know how much time it is needed sometimes to fiddle with CDK, so we definitely appreciate your efforts 🙂 .
I raised this internally and there is definitely an interest to implement a CDK construct for ESF. We are currently evaluating if and when we can prioritize this work. Stay tuned for more details! 🚀
@girodav awesome! I think it'd be a great experience for Devs so looking forward to it! Happy to help contribute however I can.
I'll likely continue working on the PoC to get it into a decent state, if only for our own use internally 😁.
@RichiCoder1 - I may have a customer scenario where we can work together to get something proofed out if you're willing. I'll ping ya on slack for more details. cc @girodav
@RichiCoder1 - I may have a customer scenario where we can work together to get something proofed out if you're willing. I'll ping ya on slack for more details. cc @girodav
I don't think I'm in any slack (external customer :D) but happy to have a chat!
Just hopping on board to say that this feature would also be useful for us. We've just started migrating to building infrastructure using the CDK instead of the AWS console, and we already have a manually deployed ESF. We're looking to move this into the CDK.
The existing ESF can't be imported directly due to CDK limitations (no stack/nested stack import support) so our current workaround is to re-deploy and switch the infrastructure to use the CDK version. Having a CDK construct would obviously make this workflow much simpler!
Describe the enhancement:
An AWS CDK Construct that encapsulates that SAR Application and has L2 support for using CDK S3 Buckets and other related resources.
Describe a specific use case for the enhancement or feature:
We're currently using CDK to manage a lot of our Elastic infrastructure. Ideally, we'll like not to drop to raw CFN or the L1 SAR Construct and use an Elastic construct directly for this.
I'd be willing to contribute a PoC if there's interest.