Correct. I'm very pedantic and usually I can't help but find flaws in all proposals :)) but I really can't think of anything here. I can see limitations though: if you use lambda layers or native code specifically for the AWS architecture etc, then you need to account for that when proxying but... It's not impossible. You also need to account for having a public IP or use a service that exposes a public ip/port and redirects to your local dev machine. The idea is not super simple in practice but it is very simple compared to the emulators and it gets you very close to 1:1 parity for all those corner cases.
Getting your live stack to call your Dev machine seems a sure fire way to slip up and accidentally send customers a test email. Or accidentally order $100,000,000 widgets.
In fact, I would say it sounds great, but in fact it's incredibly risky and monumentally stupid.
When you write "your live stack", my brain freezes. Even a simple "webapp" project in my team had 4 common stacks (prod, staging, dev, git-master which had every push to master getting deployed) plus individual stacks, one per developer, with the ability to create extra stacks for specific feature development.
Only prod had real data. Obviously (to me) you wouldn't shorcircuit lambdas in the prod env. Not even staging. Not even dev. Not even git-master. Short-circuit development environments where you explore. Very low risks there. We need to learn it's ok to fuck up, as long as we fuck up in a safe environment, nowhere near the nuclear button ;)
For a similar relay/proxy setup for development, I've found that a metadata endpoint emulation like provided in aws-vault can make it easier to have any AWS SDK calls behave the same way as they would in AWS itself. You do have to assume the role that the lambda itself would normally assume and you have to allow more than just service linked execution, but you do get to test the whole IAM chain that way as well.
Not sure that i follow you, but the setup i described would proxy the env vars as well, among them the aws credentials, so you should be able to run loudly with exactly the same liberties as the original AWS lambda.
Ha, I'm glad my simplification did not fall too short!
I did wonder with regards to the IP address. If you had a VPN set up for access to a VPC and ran the lambda in that VPC then that would be another option I think. You would just need to configure a static IP for your dev machine within the private network.
Right! I haven't explored that thought. My team kept everything serverless so we touched zero VPC/etc.
From a generic perspective, having a setup to proxy into a LAN is more valuable I think - i can imagine for instance how my team had access to certain AWS services, but not all, erc etc. But these are details - the idea would be worth exploring
