Are there better examples out there of importing e...
# awsb
bland-painting-33593
04/17/2024, 11:49 PMAre there better examples out there of importing existing AWS Lambda functions? Like, the import function generates the aws.lambda.function piece, but there's nothing about the code zip, how you can use it to then redeploy to a different account, etc. Anyone ever done any of that and can point me to examples or tutorials? I have a bunch of lambdas that I need to move from Commercial to GovCloud.
l
little-cartoon-10569
04/18/2024, 12:43 AMThe code zip is not something that can be figured out from the import, since the ZIP file is local and the import only has access to information in AWS. You'll have to read the docs about the code property of the Function class.
To change where you're deploying to, you need to create an instance of aws.Provider that points to the right place and has the right credentials, then pass that in to the Function constructor via the provider opt (third parameter).
b
bland-painting-33593
04/18/2024, 12:55 AMI mean, I can download the zip via console and cli, so I feel like that should be a part of the import?
bland-painting-33593
04/18/2024, 12:56 AMIt's partially a general complaint about the import function in general. If I point it at an ecs service, for example, I'd love for it to crawl up the chain of every component that's related, not just the service by itself. I'm not sure what good that does anyone. The dependencies could be detected, and then imports kicked off for all of them, or at least a switch that causes that to happen.
l
little-cartoon-10569
04/18/2024, 1:22 AMNo. There's no use case for deploying what's already deployed. The zip file would be generated from your source code, not from the zip file already uploaded to Lambda.
b
bland-painting-33593
04/18/2024, 2:25 AMThe use case of importing is to have a script replicating the entire stack, so if you tweak something, it takes over like it was originally deployed with pulumi versus bespoke. There's no other point to me in importing.
l
little-cartoon-10569
04/18/2024, 2:31 AMThe normal use-case for that is to write the code first, then use the code to deploy it twice (two stacks). Importing is to create the code from resources that aren't current managed: they've been created by hand. There is no stack.
little-cartoon-10569
04/18/2024, 2:32 AMWhich I guess is what you said.
little-cartoon-10569
04/18/2024, 2:34 AMGenerally there wouldn't be a case for deploying the zip as uploaded to lambda. You'd deploy a new zip, created from the original app code. Consider what would happen if you had a java lambda, or any other lambda where the zip contains compiled binaries. You couldn't change the code. You couldn't audit it. You're stuck with version X, and you don't even have a way to prove that it's the right version X, it's just the version that you pulled down at that point in time.
little-cartoon-10569
04/18/2024, 2:34 AMIf you want to do that (and imo, you shouldn't), then you can do it manually. It's easy enough to download a lambda's zip.